大部分寫程式的文化都是建立在理想或完美的程式碼上：程式碼不只要可以跑，還必須要很乾淨以及優雅。我們對於在困難的問題上可以有很聰明的解法感到驕傲。但這種完美主義對團隊來說可能是有害的，因為完美主義常導致個人看法的不同。

並沒有一個通用的標準來定義什麼是完美的程式碼。每個人對於程式碼的美學都有稍微不同的認知，這代表每個人對於完美的程式碼應該長什麼樣子都有自己的想法。如果我們每個人都受完美主義曲驅使，汲汲於讓程式碼可以完全符合自己的想像，結果就是我們會不同意團隊其他成員的想法，對於這件事爭吵不休。

作為一個成熟的程式設計師，我發現避免團隊衝突的方法是不要再去尋找完美的程式碼。下面是一些如何應用這個概念的例子：

不要被教條束縛住

程式最重要的是要可以跑，要確認最簡單的方法就是 100% 的測試覆蓋率，而且這些測試都可以通過。其他對於程式碼品質的指標都是次要的。

當你讀其他的程式時，試著不要想你自己偏好它長怎樣，不要在腦袋裡把程式重新寫一遍，就讓程式維持原狀吧。

讓你的程式碼準則簡明或乾脆沒有

Tab 還是空白？兩個空白還是四個？括號要在同一行還是獨立一行？不知道有任何一種可以免於這種辯論當中。解決這個問題的標準做法是訂定 coding style，這可以確保程式的一致性。

但不幸的是，你沒辦法寫出真正完整的 coding stlye。總是有些灰色地帶導致大家有不同的意見，命名、模式、物件塑模等等還有更多。

我們寫下的規則有時會激起熊熊大火

一個團隊我待過的團隊裡有個準則：「任何方法不得多於七行程式碼」。現在回過頭來看，沒有這個規定對我們團隊來說會更好。當我還遵守這項準則時，這項準則引起了很多的困惑以及爭論。單單這條準則在調整之後有過多的註解，大家需要把這些給記住，有些團隊則完全不管。總而言之，我們花了很多時間及力氣來維護這個準則。

這些時間用來一起寫程式增進程式碼品質會更好。每條規則都是要花成本去維護的，而且幾乎都還是會有你不認同的地方。

雖然現在我寫一個方法大部分都不會多於七行，但我不會把這條規則寫下來。

與其定下規則，讓那些程式碼 be its own standard。（譯注：這太口語了我不會翻Orz...）

不要讓 pull requests 把你給停滯了

通常就算 pull request 的程式有非常明顯的地方可以改進，我還是會把它 merge。我會這麼做有兩個原因：第一，等待修正會讓其他團隊成員無法前進；第二點比較細膩，程式應該要是隨時保持是可鍛造的，這代表，準備且預期會被改變。「完美 pull request」的文化並不鼓勵這樣，它強化了 master branch 的程式是完美不需要更改的觀念。如果我們允許不完美的程式進入 master，鼓勵更頻繁的更動，團隊會學會永遠問自己「這個程式碼沒有問題了嗎？」。

有時候這還滿違反直覺的，允許不完美的程式碼進入 master 反而可以增進程式碼的品質。

所以怎麼是好的方式來檢視 pull requests？

我的策略是，先把改動過的程式碼看過一遍，注意所有我覺得重要的地方。把我的建議限制在最重要的三個，其他都捨棄掉。

我很少會對 style 的問題像是空白的位置或是很爛的縮排提出建議。如果程式是可更動的，總有人在未來會把它修正，而在這段期間，style 的問題並不會造成任何傷害。

捨棄巨觀視角

任何超過數行的程式你就開始鑑驗它是否完美，如果你期望每個人都用跟你一樣的方法解決問題，那你恐怕錯了。如果仔細看過整個專案的程式，你恐怕會非常失望。

給你的團隊成員空見讓他們設計他們認為合適的程式，鼓勵每個人有平等的地位來設計這個系統。

當你的成員寫的程式跟你希望的樣子不一樣時，不要跟他們爭論。要記得長期來說，保持良好的團隊關係對你的團隊是很重要的。所以或許犧牲一些你個人的看法是可接受的。

我鼓勵你每天花點時間看一下團隊開發用的技術，思考你跟你的團隊的效率，什麼是方法是下個月會失效的，這當你的團隊的技巧從新手漸漸轉變成專家時尤其重要。保持隨時尋找在你們開發流程裡，有沒有什麼開始對團隊的傷害比幫助來得大。

原文：Perfect code is an illusion